There are a lot of acronyms out there. This post will clarify how we at MDriven define and use these.

MDA – Model Driven Architecture

MDA is the idea that the model for an information system can be described in a platform-independent format (PIM) and that the PIM can be transformed into artifacts that build up vital parts of the resulting IT solutions. We at MDriven are currently geared toward the .net arena; we have no ambition to be platform-independent with our MDA-Framework ECO. However, we see the benefit for all organizations to develop PIMs to secure their definitions in a longer perspective. Using the PIM approach, the investment for information design is safeguarded against shifts in technology. Our solution to PIM production is the Modlr UML design tool. Modlr is part of both the ECO-designtime-Visual-Studio-plugin and the standalone model-and-execute tool AppComplete.

• ECO allows for applying the PIM in the UI layer by transforming it into ViewModels that, in turn, can be transformed into user controls for different UI architectures: WPF, ASP.NET, Windows forms, and Silverlight.
• ECO can apply the PIM result in Handles designed for different UI architectures: WPF, ASP.NET, Windows forms, and Silverlight
• ECO can transform the PIM into c#, VB.NET, or Delphi.NET code (code generation)
• ECO can transform the PIM into relational database schemas for SQLServer, Oracle, MySql, and many more
• ECO can put the PIM to use on a server to act as an OR-mapper for other PIM-compliant services

MDD – Model Driven Development

MDD is the idea that focuses development efforts on a model and uses the model as a core definition and template for the rest of the artifacts needed for the finished product. Changes always go into the model first and then trickle down to the derived artifacts. The artifacts may be majorly derived by an automated process (code generation, DB schema generation) but could just as well be handmade. The gain in production speed and quality is largely omitted if you use the handmade approach.

ECO is model-centric. Changes go into the model first; you then update the code, keeping your handwritten additions to the largely generated domain layer by utilizing partial classes. ECO also uses the re-engineering capabilities of Visual Studio to apply changes done in the model throughout your code. The database schema is updated by a built-in evolve function that uses nonintrusive methods as much as possible, on your existing database to change it from the original form to the form that is described by the model.

DDD – Domain Driven Design

DDD is the idea that the model should adhere to the terms and definitions of the domain the system is built for. To many of us who have been modeling business for years, this is sort of a no-brainer; how would you do it any other way? Think about it like this: We can understand the domain very well but still choose to model it with abstract and nondomain-specific names - maybe to create a reusable model for other domains with the same need or maybe in an attempt to create an optimized version of the domain. That model can still be used with MDA and MDD, but it would not be DDD. DDD aims to create a ubiquitous language between developers, modelers, domain experts, and stakeholders, thus taking the technical mumbo jumbo out of creating IT systems.

ECO is great for DDD. We have not done anything extra to make it a good DDD tool apart from making it a super MDD and MDA tool. DDD describes the mindset you should have while modeling without saying anything about how to use the model once you are done.